home *** CD-ROM | disk | FTP | other *** search
/ Chip 2000 May / Chip_2000-05_cd1.bin / sharewar / FFE / GRAPH.SWG / 0070_TIFF v4.0.pas < prev   
Pascal/Delphi Source File  |  1997-05-12  |  57KB  |  1,494 lines
  1. Tag Image File Format  Rev 4.0
  2. April 31, 1987
  3.  
  4. This  memorandum  has  been prepared jointly  by  Aldus and Microsoft in
  5. conjunction   with  leading  scanner  and  printer  manufacturers.  This
  6. document does not represent a commitment on the part of either Microsoft
  7. or  Aldus  to provide support for  this  file format in any application.
  8. When  responding  to  specific  issues  raised  in  this  memo,  or when
  9. requesting  additional  tag  or field  assignments,  please address your
  10. correspondence to either:
  11.  
  12.           Tim Davenport                       Manny Vellon
  13.           Aldus Corporation                   Windows Marketing Group
  14.           411 First Ave. South                Microsoft Corporation
  15.           Suite 200                           16011 NE 36th Way
  16.           Seattle, WA  98104                  Box 97017
  17.                                               Redmond, WA  98073-9717
  18.  
  19.  
  20. Revision Notes
  21.  
  22. This release of the TIFF specification has been given a Revision number.
  23. It  is really the fourth major revision,  so the Revision number was set
  24. to 4.0.
  25.  
  26.  
  27. Abstract
  28.  
  29. This  document describes TIFF, a tag  based file format that is designed
  30. to promote the interchange of digital image data.
  31.  
  32. The  fields  were defined primarily  with desktop publishing and related
  33. applications  in  mind, although it is  conceivable  that other sorts of
  34. imaging applications may find TIFF to be useful.
  35.  
  36. The   general  scenario  for  which   TIFF  was  invented  assumes  that
  37. applications  software  for  scanning or  painting  creates a TIFF file,
  38. which  can then be read and  incorporated into a document or publication
  39. by an application such as a desktop publishing package.
  40.  
  41. The  intent  of  TIFF is to  organize  and codify existing practice with
  42. respect  to  the  definition and usage  of  desktop digital data, not to
  43. blaze new paths or promote unproven techniques. Yet a very high priority
  44. has  been given to structuring the data in such a way as to minimize the
  45. pain  of  future  additions. TIFF was  designed  to be a very extensible
  46. interchange format.
  47.  
  48. TIFF  is not a printer language or  page description language, nor is it
  49. intended to be a general document interchange standard. It may be useful
  50. as is for some image editing applications, but is probably inappropriate
  51. for  and  would thus need to  be  translated into some intermediate data
  52. structures  by other image editing applications. The primary design goal
  53. was  to  provide a rich environment  within  which the exchange of image
  54. data  between application programs can be accomplished. This richness is
  55. required  in  order  to take advantage  of  the  varying capabilities of
  56. scanners  and  similar  devices.  TIFF is  therefore  designed  to  be a
  57. superset  of existing image file formats for desktop scanners (and paint
  58. programs and anything else that produces images with pixels in them) and
  59. will be enhanced on a continuing basis as new capabilities arise.
  60.  
  61. Although  TIFF  is  claimed to be in  some  sense  a rich format, it can
  62. easily  be used for simple scanners  and applications as well, since the
  63. application  developer need only be concerned with the capabilities that
  64. he requires. The mechanisms for accomplishing this goal are discussed in
  65. the next section.
  66.  
  67. TIFF is intended to be independent of specific operating systems, filing
  68. systems,  compilers, and processors. The  only significant assumption is
  69. that  the  storage medium supports something  like  a file, defined as a
  70. sequence  of 8-bit bytes, where the bytes  are numbered from 0 to N. The
  71. largest possible TIFF file is 2**32 bytes. Since pointers (byte offsets)
  72. are used liberally, a TIFF file is most easily read from a random access
  73. device,  although  it  is  possible  to  read  and  write  TIFF files on
  74. sequential media such as magnetic tape.
  75.  
  76. The  recommended  MS-DOS  file  extension for  TIFF  files  is .TIF. The
  77. recommended  Macintosh filetype is TIFF.  Conventions in other computing
  78. environments have not yet been established.
  79.  
  80.  
  81. 1) Conformance
  82.  
  83. Many  of  the application programs that  read the contents of TIFF image
  84. files  will not support all of  the features described in this document.
  85. In  some cases, little more than  the default options will be supported.
  86. It  is  up  to  each organization  to  determine  the costs and benefits
  87. associated  with  different levels of  conformity.  Therefore, claims of
  88. conformity  to  this specification should  be interpreted with a certain
  89. amount of caution.
  90.  
  91. It  follows  that the usage of  this specification does not preclude the
  92. need for coordination between image file writers and image file readers.
  93. It  is  up to the application designer  that  initially writes a file in
  94. this format to verify that the desired file options are supported by the
  95. applications that will read the file.
  96.  
  97.  
  98. 2) Structure
  99.  
  100. In TIFF, individual fields are identified with a unique tag. This allows
  101. particular  fields to be present or absent  from the file as required by
  102. the application.
  103.  
  104. Some  TIFF  files will have only a  few fields in them; others will have
  105. many.  Software that creates TIFF files  should write out as many fields
  106. as  it  believes will be meaningful  and  useful (and no more). Software
  107. that  reads TIFF files should do the best it can with the fields that it
  108. finds there.
  109.  
  110. See Appendix A: Tag Structure Rationale.
  111.  
  112. There  are  many ways in which a  tag-oriented file format scheme can be
  113. implemented. TIFF uses the following approach:
  114.  
  115. There  are three main parts to a TIFF  file. First is a short image file
  116. header.  Next  is a directory of all the  fields that are to be found in
  117. this file. Finally, we have the data for the fields.
  118.  
  119.  
  120. 3) Header and Directory
  121.  
  122. A  TIFF  file begins with a  small  amount of positionally defined data,
  123. containing the following information:
  124.  
  125. Bytes 0-1:
  126.  
  127. The  first word of the file serves to specify the byte order used within
  128. the file. The currently defined values are:
  129.  
  130.      II        (hex 4949)
  131.      MM        (hex 4D4D)
  132.  
  133. In  the  II format, byte order is  always from least significant to most
  134. significant, for both 16-bit and 32-bit integers.
  135.  
  136. In  the  MM format, byte order is  always from most significant to least
  137. significant, for both 16-bit and 32-bit integers.
  138.  
  139. In  both  formats,  character strings  are  stored  into sequential byte
  140. locations.
  141.  
  142. It  is certainly not required that  all applications software be able to
  143. handle  both  formats. It should be  apparent which is the native format
  144. for a particular machine.
  145.  
  146. Bytes 2-3:
  147.  
  148. The  second  word  of the file is  the  TIFF version number. This number
  149. shouldnt  change. This document describes Version  42, so 42 (2A in hex)
  150. should be stored in this word.
  151.  
  152. Bytes 4-7:
  153.  
  154. This  long  word contains the offset (in  bytes) of the first Image File
  155. Directory.  The  directory may be at any  location in the file after the
  156. header but must begin on a word boundary.
  157.  
  158. (The  term  byte  offset is always used  in  this document to refer to a
  159. location  with  respect to the beginning of  the file. The first byte of
  160. the file has an offset of 0.)
  161.  
  162. An  IFD  consists of a 2-byte count  of the number of entries (i.e., the
  163. number  of  fields),  followed by a  sequence  of 12-byte field entries,
  164. followed  by  a 4-byte offset of the  next Image File Directory (or 0 if
  165. none). Each 12-byte field entry has the following format:
  166.  
  167. Bytes  0-1  contain the Tag for the  field.  Bytes 2-3 contain the field
  168. Type. Bytes 4-7 contain the Length (Count might have been a better term)
  169. of the field. Bytes 8-11 contain the file offset (in bytes) of the Value
  170. for  the  field. The Value is expected  to begin on a word boundary; the
  171. corresponding file offset will thus be an even number.
  172.  
  173. The  entries  in an IFD must be  sorted  in ascending order by Tag. Note
  174. that  this  is not the order in  which  the fields are described in this
  175. document. The Values to which directory entries point need not be in any
  176. particular order in the file.
  177.  
  178. If  the Value fits within 4 bytes,  the Offset is interpreted to contain
  179. the  Value  instead of pointing to the  Value, to save a little time and
  180. space.  If the Value is less than 4 bytes, it is left-justified. Whether
  181. or  not it fits within 4 bytes can  be determined by looking at the Type
  182. and Length of the field.
  183.  
  184. The  Length part is specified in terms of the data type. A single 16-bit
  185. word  (SHORT) has a Length of 1, not  2, for example. The data types and
  186. their lengths are described below:
  187.  
  188.      1 = BYTE.      8-bit unsigned integer.
  189.      2 = ASCII.     8-bit bytes that store ASCII codes; the last byte must
  190.                      be null.
  191.      3 = SHORT.     A 16-bit (2-byte) unsigned integer.
  192.      4 = LONG.      A 32-bit (4-byte) unsigned integer.
  193.      5 = RATIONAL.  Two LONGs: the first represents the numerator of a
  194.                      fraction, the second the denominator.
  195.  
  196. The  value of the Length part of an ASCII field entry includes the null.
  197. If padding is necessary, the Length does not include the pad byte.
  198.  
  199. The  reader should check the type to  ensure that it is what he expects.
  200. TIFF  currently  allows  more than 1 valid  type  for a given field. For
  201. example, ImageWidth and ImageLength were specified as having type SHORT.
  202. Very  large images with more than 64k  rows or columns are possible with
  203. some  devices  even  now. Rather than  add  parallel LONG tags for these
  204. fields,  it  is cleaner to allow both  SHORT and LONG for ImageWidth and
  205. similar  fields.  Writers of TIFF files  are, however, encouraged to use
  206. the  default  type  values  as  indicated  in  this  document  to insure
  207. compatbility with existing TIFF reader applications.
  208.  
  209. Note  that there may be more than one  IFD. Each IFD is said to define a
  210. subfile.  One  potential  use of subsequent  subfiles  is  to describe a
  211. sub-image  that is somehow related to the  main image, such as a reduced
  212. resolution  or  screen  resolution image.  Another  use  is to represent
  213. multiple  page images - for example, a facsimile document requiring more
  214. than  one page. Subsequent IFDs will in general contain many of the same
  215. fields  as the first IFD but will  usually point to or contain different
  216. Values for those fields.
  217.  
  218.  
  219. 4) Definitions
  220.  
  221. The TIFF structure itself is not specific to imaging applications in any
  222. way.  It  is only the definitions  of the fields themselves that jointly
  223. describe  an  image. Before we begin  describing the fields, a few image
  224. related definitions may be useful.
  225.  
  226. An  image is defined to be a  rectangular array of pixels, each of which
  227. consists  of  one or more samples.  With monochromatic data, we have one
  228. sample  per  pixel,  and sample and  pixel  can be used interchangeably.
  229. Color data usually contains three samples per pixel, as in, for example,
  230. an RGB scheme.
  231.  
  232.  
  233. 5) The Fields
  234.  
  235. The  following fields are defined in this  version of TIFF. More will be
  236. added  in future versions, if possible in such  a way so as not to break
  237. old software that encounters a newer TIFF file. An attempt has been made
  238. to  group related fields, although  the grouping is necessarily somewhat
  239. arbitrary.
  240.  
  241. The  documentation for each field contains  the name of the field (quite
  242. arbitrary, but convenient), the Tag value, the field Type, the Number of
  243. Values  (N)  expected  (per  IFD, in  the  case  of  multiple subfiles),
  244. comments  describing  the  field, and the  default,  if any. The default
  245. value is used if the field does not exist.
  246.  
  247. A fairly large number of fields has already been defined, and the number
  248. will  grow. Please keep in mind that many common images can be described
  249. using only a handful of these fields (see the Examples section).
  250.  
  251.  
  252. General Description
  253.  
  254. SubfileType
  255. Tag  = 255  (FF)
  256. Type = SHORT
  257. N    = 1
  258.  
  259. A  general  indication  of the kind of  data  that  is contained in this
  260. subfile. Currently defined values are:
  261. 1 = full resolution image data ImageWidth, ImageLength, and StripOffsets
  262. are required fields.
  263. 2   =  reduced  resolution  image   data  ImageWidth,  ImageLength,  and
  264. StripOffsets  are required fields. It is  further assumed that a reduced
  265. resolution  image  is  a  reduced version  of  the  entire extent of the
  266. corresponding full resolution data.
  267. 3  =  Single  page  of  a  multi-page  image  (see  the  PageNumber  tag
  268. description).
  269.  
  270. If  your  kind of image data  doesnt fit nicely into either description,
  271. contact  either  Aldus or Microsoft to  define an additional value. Note
  272. that  both  image  types can be found  in  a single TIFF file, with each
  273. subfile described by its own IFD. No default.
  274.  
  275.  
  276. Data Architecture
  277.  
  278. ImageWidth
  279. Tag  = 256  (100)
  280. Type = SHORT
  281. N    = 1
  282.  
  283. The  images  width, in pixels (X:  horizontal). The number of columns in
  284. the image. No default.
  285.  
  286.  
  287. ImageLength
  288. Tag  = 257  (101)
  289. Type = SHORT
  290. N    = 1
  291.  
  292. The  images length (height) in pixels  (Y: vertical). The number of rows
  293. (sometimes  described  as  scan  lines)  in  the  image. ImageLength and
  294. ImageWidth  refer  only to how the pixels  are stored in the file and do
  295. not  imply anything about where the visual top or left side of the image
  296. may be. See Orientation for this information. No default.
  297.  
  298.  
  299. RowsPerStrip
  300. Tag  = 278  (116)
  301. Type = SHORT or LONG
  302. N    = 1
  303.  
  304. The  number  of rows per strip. The  image data is organized into strips
  305. for  fast access to individual rows  when the data is compressed (though
  306. this field is valid even if the data is not compressed).
  307.  
  308. Note   that  either  SHORT  or  LONG  values  can  be  used  to  specify
  309. RowsPerStrip.  SHORT values may be used  for small TIFF files. It should
  310. be noted, however, that earlier TIFF specifications required LONG values
  311. and that some software may not expect SHORT values.
  312.  
  313. Default is 2**32 - 1, which is effectively infinity. That is, the entire
  314. image is one strip.
  315.  
  316.  
  317. [StripsPerImage]
  318. N    = 1
  319.  
  320. The  number of strips per image. This value is not a field, since it can
  321. be  computed  from two other fields, but  it  is convenient to give it a
  322. name in order to clarify the use of other fields. The equation to use is
  323. StripsPerImage  =  (ImageLength  +  RowsPerStrip  -  1)  / RowsPerStrip,
  324. assuming integer arithmetic.
  325.  
  326.  
  327. StripOffsets
  328. Tag  = 273  (111)
  329. Type = SHORT or LONG
  330. N    = StripsPerImage for PlanarConfiguration equal to 1.
  331.      = SamplesPerPixel * StripsPerImage for PlanarConfiguration equal to 2
  332.  
  333. For  each strip, the byte offset of  that strip. The offset is specified
  334. with  respect to the beginning of the  TIFF file. Note that this implies
  335. that  each  strip has a location  independent  of the locations of other
  336. strips.  This  feature may be  useful  for certain editing applications.
  337. This  field  is  the only way for a  reader  to find the image data, and
  338. hence must exist.
  339.  
  340. Note  that either SHORT or LONG values  can be used to specify the strip
  341. offsets.  SHORT  values may be used for  small  TIFF files. It should be
  342. noted,  however,  that earlier TIFF  specifications  required LONG strip
  343. offsets and that some software may not expect SHORT values. No default.
  344.  
  345.  
  346. StripByteCounts
  347. Tag  = 279  (117)
  348. Type = LONG
  349. N    = StripsPerImage for PlanarConfiguration equal to 1.
  350.      = SamplesPerPixel * StripsPerImage for PlanarConfiguration equal to 2
  351.  
  352. For each strip, the number of bytes in that strip. No default.
  353.  
  354.  
  355. SamplesPerPixel
  356. Tag  = 277  (115)
  357. Type = SHORT
  358. N    = 1
  359.  
  360. The  number of samples per pixel. Usually 1 for monochromatic data and 3
  361. for color data (i.e. one sample for each of the color planes.) Default =
  362. 1.
  363.  
  364.  
  365. BitsPerSample
  366. Tag  = 258  (102)
  367. Type = SHORT
  368. N    = SamplesPerPixel
  369.  
  370. Number  of bits per sample. Note that this tag allows a different number
  371. of  bits  per  sample  for each  sample  corresponding  to  a pixel. For
  372. example,  RGB color data could use a different number of bits per sample
  373. for each of the three color planes. Default = 1.
  374.  
  375.  
  376. PlanarConfiguration
  377. Tag  = 284  (11C)
  378. Type = SHORT
  379. N    = 1
  380.  
  381. 1  =  the sample values for each  pixel are stored contiguously, so that
  382. there   is  a  single  image  plane.  See  PhotometricInterpretation  to
  383. determine  the  order  of  the samples within  the  pixel  data.
  384. 2  =  the  samples are stored in  separate  sample planes. The values in
  385. StripOffsets  and  StripByteCounts are then  arranged as a 2-dimensional
  386. array, with SamplesPerPixel rows and StripsPerImage columns. (All of the
  387. columns  for  row 0 are stored first,  followed by the columns of row 1,
  388. and so on.) PhotometricInterpretation describes the type of data that is
  389. stored in each sample plane.
  390.  
  391. If  SamplesPerPixel is 1, a PlanarConfiguration value of 1 is equivalent
  392. to a value of 2. No default.
  393.  
  394.  
  395. Compression
  396. Tag  = 259  (103)
  397. Type = SHORT
  398. N    = SamplesPerPixel for PlanarConfiguration equal to 1 or 2.
  399.  
  400. Note  that  a  value  is provided  for  each  sample, allowing different
  401. compression schemes to be applied to different planes of data.
  402.  
  403. 1  =  No compression, but pack data  into  bytes as tightly as possible,
  404. with  no unused bits except at the end of a row. See also FillOrder. The
  405. bytes are stored as an array of type BYTE, for BitsPerSample <= 8, SHORT
  406. if  BitsPerSample  > 8 and <= 16, and  LONG if BitsPerSample > 16 and <=
  407. 32.  The  byte  ordering of data >8  bits  must  be consistent with that
  408. specified  in  the TIFF file header (bytes  0 and 1). Intel format files
  409. will  have  the least significant  bytes preceeding the most significant
  410. bytes while Motorola format files will have the opposite.
  411.  
  412. If  the  number  of  bits per sample is  not  a  power of 2, and you are
  413. willing  to  give up some space for  better performance, you may wish to
  414. use  the  next  higher  power of 2.  For  example,  if  your data can be
  415. represented  in 6 bits, you may wish to  specify that it is 8 bits deep.
  416. If  you  take this approach, you  should be sure that MinSampleValue and
  417. MaxSampleValue   are  given  correct  values  (probably  0  and  63  for
  418. intrinsically  6-bit data.) TIFF file  readers should use MinSampleValue
  419. and  MaxSampleValue to determine the range  of values in the data rather
  420. than BitsPerSample.
  421.  
  422. Rows are required to begin on byte boundaries.
  423.  
  424. 2  =  CCITT Group 3 1-Dimensional  Modified Huffman run length encoding.
  425. See  Appendix  B:  Data Compression Scheme  2.  BitsPerSample must be 1,
  426. since this type of compression is defined only for binary images.
  427.  
  428. 3  =  Facsimile-compatible  CCITT  Group  3,  exactly  as  specified  in
  429. Standardization   of   Group   3   facsimile   apparatus   for  document
  430. transmission,  Recommendation T.4, Volume  VII, Fascicle VII.3, Terminal
  431. Equipment  and  Protocols  for  Telematic  Services,  The  International
  432. Telegraph  and  Telephone Consultative  Committee (CCITT), Geneva, 1985,
  433. pages  16  through  31. Each strip must  begin  on a byte boundary. (But
  434. recall that an image can be a single strip.) Rows that are not the first
  435. row of a strip are not required to begin on a byte boundary. The data is
  436. stored  as bytes, not words byte-reversal  is not allowed. Note that the
  437. FillOrder  field still applies. See the  Group3Options field for Group 3
  438. options such as 1D vs 2D coding.
  439.  
  440. 4  =  Facsimile-compatible  CCITT  Group  4,  exactly  as  specified  in
  441. Facsimile  Coding  Schemes  and  Coding  Control  Functions  for Group 4
  442. Facsimile  Apparatus,  Recommendation T.6,  Volume  VII, Fascicle VII.3,
  443. Terminal   Equipment   and   Protocols   for   Telematic  Services,  The
  444. International  Telegraph  and Telephone  Consultative Committee (CCITT),
  445. Geneva,  1985,  pages  40 through 48. Each  strip  must  begin on a byte
  446. boundary. Rows that are not the first row of a strip are not required to
  447. begin  on a byte boundary. The data  is stored as bytes, not words. Note
  448. that  the FillOrder field still applies. See the Group4Options field for
  449. Group 4 options.
  450.  
  451. 32771  =  the same thing as  Compression type 1 (no compression), except
  452. that  each  row begins on the  next  available word boundary, instead of
  453. byte boundary.
  454.  
  455. 32773   =  PackBits  compression,   a  relatively  simple  byte-oriented
  456. run-length scheme. See Appendix C.
  457.  
  458. Data   compression  only  applies  to  pixel  data,  as  pointed  to  by
  459. StripOffsets. All other TIFF information is unaffected.
  460.  
  461. To be determined are additional compression schemes for gray and colored
  462. images. We encourage your suggestions, especially if accompanied by full
  463. specifications and performance information. It is of course desirable to
  464. minimize the number of compression schemes that are being used, but this
  465. is  clearly  an  area  in which  extremely  significant  time  and space
  466. tradeoffs exist. Default = 1.
  467.  
  468.  
  469. Group3Options
  470. Tag  = 292  (124)
  471. Type = LONG
  472. N    = 1
  473.  
  474. This field is made up of a set of 32 flag bits. Unused bits are expected
  475. to  be 0. Bit 0 is the low-order bit.  It is probably not safe to try to
  476. read  the  file if any bit of this  field  is set that you dont know the
  477. meaning of.
  478.  
  479. Bit 0 is 1 for 2-dimensional coding (else 1-dimensional is assumed). For
  480. 2-D  coding, if more than one strip  is specified, each strip must begin
  481. with  a  1-dimensionally coded line. That  is,  RowsPerStrip should be a
  482. multiple of Parameter K as documented in the CCITT specification.
  483.  
  484. Bit 1 is 1 if uncompressed mode is used.
  485.  
  486. Bit  2  is 1 if fill bits have  been added as necessary before EOL codes
  487. such  that  EOL  always  ends  on  a  byte  boundary,  thus  ensuring an
  488. eol-sequence of a 1 byte preceded by a zero nibble: xxxx-0000 0000-0001.
  489.  
  490. Default is 0, for basic 1-dimensional coding.
  491.  
  492.  
  493. Group4Options
  494. Tag  =  293  (125)
  495. Type = LONG
  496. N    = 1
  497.  
  498. This field is made up of a set of 32 flag bits. Unused bits are expected
  499. to  be 0. Bit 0 is the low-order bit.  It is probably not safe to try to
  500. read  the  file if any bit of this  field  is set that you dont know the
  501. meaning  of.  Gray scale and color  coding  schemes are under study, and
  502. will be added when finalized.
  503.  
  504. For 2-D coding, each strip is encoded as if it were a separate image. In
  505. particular, each strip begins on a byte boundary; and the coding for the
  506. first row of a strip is encoded independently of the previous row, using
  507. horizontal  codes, as if the previous  row is entirely white. Each strip
  508. ends with the 24-bit end-of-facsimile block (EOFB).
  509.  
  510. Bit 0 is unused.
  511.  
  512. Bit 1 is 1 if uncompressed mode is used.
  513.  
  514. Default is 0, for basic 2-dimensional binary compression.
  515.  
  516.  
  517. FillOrder
  518. Tag  = 266  (10A)
  519. Type = SHORT
  520. N    = 1
  521.  
  522. The order of data values within a byte. 1 = most significant bits of the
  523. byte  are filled first. That is, data values (or code words) are ordered
  524. from high order bit to low order bit within a byte.
  525.  
  526. 2 = least significant bits are filled first.
  527. Default is FillOrder = 1.
  528.  
  529.  
  530. Threshholding
  531. Tag  = 263  (107)
  532. Type = SHORT
  533. N    = 1
  534.  
  535. 1 = a bilevel line art scan.  BitsPerSample must be 1.
  536. 2 = a halftone or dithered scan, usually of continuous tone data such as
  537. photographs.  BitsPerSample must be 1.
  538. 3 = Error Diffused.
  539. Default is Threshholding = 1.
  540.  
  541.  
  542. CellWidth
  543. Tag  = 264  (108)
  544. Type = SHORT
  545. N    = 1
  546.  
  547. The width, in 1-bit samples, of the dithering/halftoning matrix. Assumes
  548. that  Threshholding  =  2.  That  is,  this  field  is  only relevant if
  549. Threshholding = 2.
  550.  
  551. No default.
  552.  
  553.  
  554. CellLength
  555. Tag  = 265  (109)
  556. Type = SHORT
  557. N    = 1
  558.  
  559. The  length,  in  1-bit  samples,  of  the  dithering/halftoning matrix.
  560. Assumes that Threshholding = 2. This field and the previous field may be
  561. useful  for  converting  from  halftoned to  true  gray  level  data. No
  562. default.
  563.  
  564.  
  565. Photometrics
  566.  
  567. These  fields are useful in determining the visual meaning of the sample
  568. data.
  569.  
  570.  
  571. MinSampleValue
  572. Tag  = 280  (118)
  573. Type = SHORT
  574. N    = SamplesPerPixel
  575.  
  576. The minimum valid sample value.
  577. Default is 0.
  578.  
  579.  
  580. MaxSampleValue
  581. Tag  = 281  (119)
  582. Type = SHORT
  583. N    = SamplesPerPixel
  584.  
  585. The maximum valid sample value.
  586. Default is 2**(BitsPerSample) - 1.
  587.  
  588.  
  589. PhotometricInterpretation
  590. Tag  = 262  (106)
  591. Type = SHORT
  592. N    = 1
  593.  
  594. 0  = MinSampleValue should be imaged  as white. MaxSampleValue should be
  595. imaged  as black. If the bit-map  represents gray scale, then the values
  596. between  the  minimum  and maximum  sample  values should be interpreted
  597. according  to  either  the  gray  scale  response  curve information (if
  598. included)  or  according to the result  of some more arbitrary rule. See
  599. GrayResponseCurve.
  600.  
  601. 1  = MinSampleValue should be imaged  as black. MaxSampleValue should be
  602. imaged  as white. If the bit-map  represents gray scale, then the values
  603. between  the  minimum  and maximum  sample  values should be interpreted
  604. according  to  either  the  gray  scale  response  curve information (if
  605. included) or according to the result of some more arbitrary rule.
  606.  
  607. 2  = RGB. In the RGB model, a color is described as a combination of the
  608. three  primary  colors  of light (red,  green,  and  blue) in particular
  609. concentrations. For each of the three samples, MinSampleValue represents
  610. minimum  intensity, and MaxSampleValue represents maximum intensity. For
  611. PlanarConfiguration  = 1, the samples are  stored in the indicated order
  612. within    a   pixel:   first   Red,   then   Green,   then   Blue.   For
  613. PlanarConfiguration  = 2, the sample planes  are stored in the indicated
  614. order:  first the Red sample plane, then  the Green plane, then the Blue
  615. plane.
  616.  
  617. The  Red,  Green and Blue intensity  values are defined according to the
  618. NTSC specifications for primary color chromaticity. These specifications
  619. assume  the  illumination to be CIE D6500.  See  the Red, Green and Blue
  620. color response curve tags.
  621.  
  622. Note:  some  compression  schemes, such as  the  CCITT  schemes, imply a
  623. particular PhotometricInterpretation. Therefore, when reading such data,
  624. TIFF readers should ignore PhotometricInterpretation. And, ideally, TIFF
  625. writers should not write out the field when using one of these schemes.
  626.  
  627. No default.
  628.  
  629.  
  630. GrayResponseUnit
  631. Tag  = 290 (122)
  632. Type = SHORT
  633. N    = 1
  634.  
  635. 1 = number represents tenths of a unit.
  636. 2 = number represents hundredths of a unit.
  637. 3 = number represents thousandths of a unit.
  638. 4 = number represents ten-thousandths of a unit.
  639. 5 = number represents hundred-thousandths of a unit.
  640. Default is 2.
  641.  
  642.  
  643. GrayResponseCurve
  644. Tag  = 291 (123)
  645. Type = SHORT
  646. N    = 2**BitsPerSample
  647.  
  648. The  purpose of the gray response curve and the gray units is to further
  649. provide  photometric  interpretation  information  for  gray scale image
  650. data. The gray response curve specifies for given levels of gray between
  651. the  minimum and maximum sample values the actual photometric gray level
  652. of the value. It represents this gray level in terms of optical density.
  653.  
  654. The  GrayScaleResponseUnits  specifies the  accuracy  of the information
  655. contained  in the curve. Since optical  density is specified in terms of
  656. fractional  numbers, this tag is necessary  to know how to interpret the
  657. stored  integer  information. For  example, if GrayScaleResponseUnits is
  658. set  to  4  (ten-thousandths of  a  unit),  and a GrayScaleResponseCurve
  659. number  for  gray  level 4 is 3455,  then  the resulting actual value is
  660. 0.3455.
  661.  
  662. If the gray scale response curve is known for the data in the TIFF file,
  663. and  if  the gray scale response of  the output device is known, then an
  664. intelligent conversion can be made between the input data and the output
  665. device. For example, the output can be made to look just like the input.
  666. In  addition, if the input image lacks contrast (as can be seen from the
  667. response curve), then appropriate contrast enhancements can be made.
  668.  
  669. The purpose of the grey scale response curve is to act as a lookup table
  670. mapping  values  from  0 to  2**BitsPerSample-1  into specific intensity
  671. values.  Refer to the PhotometricInterpretation tag to determine how the
  672. mapping should be done.
  673.  
  674.  
  675. ColorResponseUnit
  676. Tag  = 300 (12C)
  677. Type = SHORT
  678. N    = 1
  679.  
  680. 1 = number represents tenths of a unit.
  681. 2 = number represents hundredths of a unit.
  682. 3 = number represents thousandths of a unit.
  683. 4 = number represents ten-thousandths of a unit.
  684. 5 = number represents hundred-thousandths of a unit.
  685. Default is 2.
  686.  
  687.  
  688. ColorResponseCurves
  689. Tag  = 301 (12D)
  690. Type = SHORT
  691. N    = 2**BitsPerSample (for Red samples) +
  692.                 2**BitsPerSample (for Green samples) +
  693.                 2**BitsPerSample (for Blue samples)
  694.  
  695. This  tag  defines three color response  curves (one each for Red, Green
  696. and  Blue  color  information). The  curves  are stored sequentially (in
  697. red-green-blue order). The size of each table is 2**BitsPerSample, using
  698. the  BitsPerSample  value  corresponding to  the  respective  color. The
  699. ColorResponseUnit further specifies how each entry in the table is to be
  700. interpreted.
  701.  
  702. The  purpose  of the color response curves  is  to act as a lookup table
  703. mapping  values  from  0 to  2**BitsPerSample-1  into specific intensity
  704. values.  The  intensity  values  are  as  specified  by  the  NTSC color
  705. strandard assuming illumination to be CIE D6500.
  706.  
  707.  
  708. Correspondence to the Physical World
  709.  
  710. XResolution
  711. Tag  = 282  (11A)
  712. Type = RATIONAL
  713. N    = 1
  714.  
  715. The  number of pixels per ResolutionUnit (see below) in the X direction,
  716. i.e.,  in the ImageWidth direction. It is, of course, not mandatory that
  717. the  image be actually printed at the size implied by this parameter. It
  718. is up to the application to use this information as it wishes.
  719.  
  720. As  is the case for many of these fields, XResolution may be invalid and
  721. irrelevant   for  some  images  (e.g.,  images  made  with  a  hand-held
  722. digitizing  camera,  which  has a  three-dimensional  nature) and should
  723. therefore be absent from the image file. No default.
  724.  
  725.  
  726.  
  727. YResolution
  728. Tag  = 283  (11B)
  729. Type = RATIONAL
  730. N    = 1
  731.  
  732. The number of pixels per ResolutionUnit in the Y direction, i.e., in the
  733. ImageLength direction. No default.
  734.  
  735.  
  736. ResolutionUnit
  737. Tag  = 296 (128)
  738. Type = SHORT
  739. N    = 1
  740.  
  741. To be used with XResolution and YResolution.
  742. 1 = no absolute unit of measurement.  Used for images that may have a
  743. non-square aspect ratio, but no meaningful absolute dimensions.
  744. 2 = inch
  745. 3 = centimeter
  746. Default is 2
  747.  
  748.  
  749. Orientation
  750. Tag  = 274 (112)
  751. Type = SHORT
  752. N    = 1
  753.  
  754. 1 =  The 0th row represents the visual top of the image, and the 0th column
  755. represents the visual left hand side.
  756. 2 =  The 0th row represents the visual top of the image, and the 0th column
  757. represents the visual right hand side.
  758. 3 =  The 0th row represents the visual bottom of the image, and the 0th column
  759. represents the visual right hand side.
  760. 4 =  The 0th row represents the visual bottom of the image, and the 0th column
  761. represents the visual left hand side.
  762. 5 =  The 0th row represents the visual left hand side of the image, and the 0th
  763. column represents the visual top.
  764. 6 =  The 0th row represents the visual right hand side of the image, and the
  765. 0th column represents the visual top.
  766. 7 =  The 0th row represents the visual right hand side of the image, and the
  767. 0th column represents the visual bottom.
  768. 8 =  The 0th row represents the visual left hand side of the image, and the 0th
  769. column represents the visual bottom.
  770. Default is 1.
  771.  
  772.  
  773. Document Context
  774.  
  775. DocumentName
  776. Tag  = 269  (10D)
  777. Type = ASCII
  778.  
  779. The name of the document from which this image was scanned.
  780. No default.
  781.  
  782.  
  783. PageName
  784. Tag  = 285  (11D)
  785. Type = ASCII
  786.  
  787. The name of the page from which this image was scanned.
  788. No default.
  789.  
  790.  
  791. XPosition
  792. Tag  = 286  (11E)
  793. Type = RATIONAL
  794.  
  795. The X offset of the left side of the image, with respect to the left side of
  796. the page, in inches.
  797. No default.
  798.  
  799.  
  800. YPosition
  801. Tag  = 287  (11F)
  802. Type = RATIONAL
  803.  
  804. The Y offset of the top of the image, with respect to the top of the page, in
  805. inches.  In the TIFF coordinate scheme, the positive Y direction is down, so
  806. that YPosition is always positive.
  807. No default.
  808.  
  809.  
  810. PageNumber
  811. Tag  = 297  (129)
  812. Type = SHORT
  813. N    = 2
  814.  
  815. This tag is used to specify page numbers of a multiple page (e.g. facsimile)
  816. document.  Two SHORT values are specified.  The first value is the page number;
  817. the second value is the total number of pages in the document.
  818.  
  819. Note that pages need not appear in numerical order.
  820.  
  821.  
  822.  
  823. Miscellaneous Strings
  824.  
  825. ImageDescription
  826. Tag  = 270 (10E)
  827. Type = ASCII
  828.  
  829. Useful or interesting information about the image.
  830. No default.
  831.  
  832.  
  833. Make
  834. Tag  = 271  (10F)
  835. Type = ASCII
  836.  
  837. The name of the scanner manufacturer.
  838. No default.
  839.  
  840.  
  841. Model
  842. Tag  = 272  (110)
  843. Type = ASCII
  844.  
  845. The model name/number of the scanner.
  846. No default.
  847.  
  848.  
  849. Storage Management
  850.  
  851. These  fields  may  be  useful  in  certain  dynamic editing situations.
  852. Software  that  merely reads TIFF files  will  probably not need to care
  853. about  these fields. And, of course, software that creates TIFF files is
  854. by no means required to write these fields.
  855.  
  856. FreeOffsets
  857. Tag  = 288  (120)
  858. Type = LONG
  859.  
  860. For each free block in the file, its byte offset.
  861. No default.
  862.  
  863.  
  864. FreeByteCounts
  865. Tag  = 289  (121)
  866. Type = LONG
  867.  
  868. For each free block in the file, the number of bytes in the block.
  869.  
  870.  
  871.  
  872. 6) Examples
  873.  
  874. A  binary  image  from a paint  program  might contain only SubfileType,
  875. ImageWidth,  ImageLength,  StripOffsets,  and  PhotometricInterpretation
  876. fields.
  877.  
  878. A  typical line art scan might  require that XResolution and YResolution
  879. be added to the above list.
  880.  
  881.  
  882.  
  883. 7) Private Fields
  884.  
  885. An  organization may wish to store  with the image file information that
  886. is  meaningful only to that organization.  Tags numbered 32768 or higher
  887. are  reserved  for  that purpose.  Upon  request, the administrator will
  888. allocate  and  register a block of  private tags for an organization, to
  889. avoid possible conflicts with other organizations.
  890.  
  891. Private  enumerated  values  can be  accommodated  in a similar fashion.
  892. Enumeration  constants numbered 32768 or higher are reserved for private
  893. usage.  Upon  request,  the administrator  will  allocate and register a
  894. block  of  enumerated values for a  particular  field, to avoid possible
  895. conflicts.
  896.  
  897. Tags  and values which are allocated in the private number range are not
  898. prohibited   from   being  included  in   a   future  revision  of  this
  899. specification. Several such instances can be found in this revision.
  900.  
  901.  
  902. 8) A List of Possible Future Enhancements
  903.  
  904. In  the  future  TIFF  will  very  likely  be  expanded  to support more
  905. compression  schemes, more photometric schemes, color lookup tables, and
  906. non-rectangular   images.   Please   refer   all   questions   regarding
  907. enhancements  to  TIFF  to the contacts  listed  at the beginning of the
  908. document.  Written  submissions  should be  in  Microsoft  Windows Write
  909. format,   to  ensure  timely  and   error-free  incorporation  into  the
  910. specification.
  911. Tag Image File Format  Rev 4.0
  912. April 31, 1987
  913.  
  914. Appendix A: Tag Structure Rationale
  915.  
  916.  
  917. A  file  format  is defined by  both  form  (structure) and content. The
  918. content  of  TIFF  consists of definitions  of  individual fields. It is
  919. therefore  the  content  that  we  are  ultimately  interested  in.  The
  920. structure merely tells us how to find the fields.
  921.  
  922. Yet the structure deserves serious consideration for a number of reasons
  923. that  are  not  at  all obvious  at  first  glance.  Since the structure
  924. described herein departs significantly from several other approaches, it
  925. may be useful to discuss the rationale behind it.
  926.  
  927. The simplest, most straightforward structure for something like an image
  928. file is a positional format. In a positional scheme, the location of the
  929. data  defines what the data means. For  example, the field for number of
  930. rows might begin at byte offset 30 in the image file.
  931.  
  932. This  approach is simple and easy to implement and is perfect for static
  933. environments.  But  if  a significant amount  of  ongoing change must be
  934. accommodated,  some  subtle  problems  start  showing  up.  For example,
  935. suppose  that  a field must be superseded  by a new, more general field.
  936. You  could  bump a version number to  flag the change. Then new software
  937. has  no  problem  doing something sensible  with  old  data, and all old
  938. software  will reject the new data,  even software that didnt care about
  939. the  old  field.  This may seem like  no  more than a minor annoyance at
  940. first glance, but causing old software to break more often than it would
  941. really  need to can be very costly and, inevitably, causes much gnashing
  942. of teeth among customers.
  943.  
  944. Furthermore,  it  can be avoided. One approach  is to store a valid flag
  945. bit  for  each field. Now you dont  have  to bump the version number, as
  946. long  as you can put the new  field somewhere that doesnt disturb any of
  947. the old fields. Old software that didnt care about that old field anyway
  948. can  continue  to function. (Old software  that  did care will of course
  949. have  to  give up, but this is an  unavoidable  price to be paid for the
  950. sake of progress, barring total omniscience.)
  951.  
  952. Another  problem  that  crops up frequently  is  that certain fields are
  953. likely  to make sense only if other  fields have certain values. This is
  954. not  such  a  serious  problem in  practice;  it  just makes things more
  955. confusing.  Nevertheless, we note that the  valid flag bits described in
  956. the previous paragraph can help to clarify the situation.
  957.  
  958. Field-dumping  programs  can be very  helpful for diagnostic purposes. A
  959. desirable  characteristic  of such a program  is  that it doesnt have to
  960. know  much about what it is dumping.  In particular, it would be nice if
  961. the  program  could  dump ASCII data  in  ASCII  format, integer data in
  962. integer format, and so on, without having to teach the program about new
  963. fields all the time. So maybe we should add a data type component to our
  964. fields,  plus  information  on how long the  field  is, so that our dump
  965. program  can  walk  through the fields  without  knowing what the fields
  966. mean.
  967.  
  968. But  note that if we add one more  component to each field, namely a tag
  969. that  tells  what the field means, we  can  dispense with the valid flag
  970. bits, and we can also avoid wasting space on the non-valid fields in the
  971. file.  Simple  image creation applications  can write out several fields
  972. and be done.
  973.  
  974. We have now derived the essentials of a tag based image file format.
  975.  
  976. Finally,  a caveat. A tag based scheme cannot guarantee painless growth.
  977. But is does provide a useful tool to assist in the process.
  978.  
  979.  
  980.  
  981.  
  982.                       Table 1/T.4
  983.  
  984.                      Make-up codes
  985.  
  986.                    Terminating codes
  987.  
  988.  
  989. White run        Code word       Black run       Code word
  990.  length                                           length
  991.  
  992.      0           00110101           0            0000110111
  993.      1           000111             1            010
  994.      2           0111               2            11
  995.      3           1000               3            10
  996.      4           1011               4            011
  997.      5           1100               5            0011
  998.      6           1110               6            0010
  999.      7           1111               7            00011
  1000.      8           10011              8            000101
  1001.      9           10100              9            000100
  1002.     10           00111             10            0000100
  1003.     11           01000             11            0000101
  1004.     12           001000            12            0000111
  1005.     13           000011            13            00000100
  1006.     14           110100            14            00000111
  1007.     15           110101            15            000011000
  1008.     16           101010            16            0000010111
  1009.     17           101011            17            0000011000
  1010.     18           0100111           18            0000001000
  1011.     19           0001100           19            00001100111
  1012.     20           0001000           20            00001101000
  1013.     21           0010111           21            00001101100
  1014.     22           0000011           22            00000110111
  1015.     23           0000100           23            00000101000
  1016.     24           0101000           24            00000010111
  1017.     25           0101011           25            00000011000
  1018.     26           0010011           26            000011001010
  1019.     27           0100100           27            000011001011
  1020.     28           0011000           28            000011001100
  1021.     29           00000010          29            000011001101
  1022.     30           00000011          30            000001101000
  1023.     31           00011010          31            000001101001
  1024.     32           00011011          32            000001101010
  1025.     33           00010010          33            000001101011
  1026.     34           00010011          34            000011010010
  1027.     35           00010100          35            000011010011
  1028.     36           00010101          36            000011010100
  1029.     37           00010110          37            000011010101
  1030.     38           00010111          38            000011010110
  1031.     39           00101000          39            000011010111
  1032.     40           00101001          40            000001101100
  1033.     41           00101010          41            000001101101
  1034.     42           00101011          42            000011011010
  1035.     43           00101100          43            000011011011
  1036.     44           00101101          44            000001010100
  1037.     45           00000100          45            000001010101
  1038.     46           00000101          46            000001010110
  1039.     47           00001010          47            000001010111
  1040.     48           00001011          48            000001100100
  1041.     49           01010010          49            000001100101
  1042.     50           01010011          50            000001010010
  1043.     51           01010100          51            000001010011
  1044.     52           01010101          52            000000100100
  1045.     53           00100100          53            000000110111
  1046.     54           00100101          54            000000111000
  1047.     55           01011000          55            000000100111
  1048.     56           01011001          56            000000101000
  1049.     57           01011010          57            000001011000
  1050.     58           01011011          58            000001011001
  1051.     59           01001010          59            000000101011
  1052.     60           01001011          60            000000101100
  1053.     61           00110010          61            000001011010
  1054.     62           00110011          62            000001100110
  1055.     63           00110100          63            000001100111
  1056.  
  1057.  
  1058.  
  1059.                       Table 2/T.4
  1060.  
  1061.                      Make-up codes
  1062.  
  1063.  
  1064. White run        Code word       Black run       Code word
  1065.  length                                           length
  1066.  
  1067.     64           11011             64            0000001111
  1068.    128           10010            128            000011001000
  1069.    192           010111           192            000011001001
  1070.    256           0110111          256            000001011011
  1071.    320           00110110         320            000000110011
  1072.    384           00110111         384            000000110100
  1073.    448           01100100         448            000000110101
  1074.    512           01100101         512            0000001101100
  1075.    576           01101000         576            0000001101101
  1076.    640           01100111         640            0000001001010
  1077.    704           011001100        704            0000001001011
  1078.    768           011001101        768            0000001001100
  1079.    832           011010010        832            0000001001101
  1080.    896           011010011        896            0000001110010
  1081.    960           011010100        960            0000001110011
  1082.   1024           011010101        1024           0000001110100
  1083.   1088           011010110        1088           0000001110101
  1084.   1152           011010111        1152           0000001110110
  1085.   1216           011011000        1216           0000001110111
  1086.   1280           011011001        1280           0000001010010
  1087.   1344           011011010        1344           0000001010011
  1088.   1408           011011011        1408           0000001010100
  1089.   1472           010011000        1472           0000001010101
  1090.   1536           010011001        1536           0000001011010
  1091.   1600           010011010        1600           0000001011011
  1092.   1664           011000           1664           0000001100100
  1093.   1728           010011011        1728           0000001100101
  1094.   EOL            000000000001     EOL            000000000001
  1095.  
  1096.  
  1097.  
  1098. Note it is recognized that machines exist which accommodate larger paper
  1099. widths  whilst  maintaining  the  standard  horizontal  resolution. This
  1100. option  has  been provided for by the  addition  of the Make-up code set
  1101. defined as follows:
  1102.  
  1103.  
  1104.                      Run length              Make-up codes
  1105.                   (black and white)
  1106.  
  1107.                         1792                  00000001000
  1108.                         1856                  00000001100
  1109.                         1920                  00000001101
  1110.                         1984                  000000010010
  1111.                         2048                  000000010011
  1112.                         2112                  000000010100
  1113.                         2176                  000000010101
  1114.                         2240                  000000010110
  1115.                         2304                  000000010111
  1116.                         2368                  000000011100
  1117.                         2432                  000000011101
  1118.                         2496                  000000011110
  1119.                         2560                  000000011111
  1120.  
  1121.  
  1122.  
  1123.  
  1124. Appendix B: Data Compression Scheme 2
  1125.  
  1126.  
  1127. Abstract
  1128.  
  1129. This  document  describes a method for  compressing bilevel data that is
  1130. based  on  the  CCITT  Group 3  1D  facsimile  compression scheme. It is
  1131. intended that it be used in conjunction with the Tag Image File Format.
  1132.  
  1133.  
  1134. References
  1135.  
  1136. 1.   Standardization  of  Group  3   facsimile  apparatus  for  document
  1137. transmission,  Recommendation T.4, Volume  VII, Fascicle VII.3, Terminal
  1138. Equipment  and  Protocols  for  Telematic  Services,  The  International
  1139. Telegraph  and  Telephone Consultative  Committee (CCITT), Geneva, 1985,
  1140. pages 16 through 31.
  1141.  
  1142. 2.  Facsimile  Coding Schemes and Coding  Control  Functions for Group 4
  1143. Facsimile  Apparatus,  Recommendation T.6,  Volume  VII, Fascicle VII.3,
  1144. Terminal   Equipment   and   Protocols   for   Telematic  Services,  The
  1145. International  Telegraph  and Telephone  Consultative Committee (CCITT),
  1146. Geneva, 1985, pages 40 through 48.
  1147.  
  1148.  
  1149. Relationship to the CCITT Specifications
  1150.  
  1151. The  CCITT  Group 3 and  Group  4 specifications describe communications
  1152. protocols  for a particular class of devices. They are not by themselves
  1153. sufficient  to  describe a disk  data  format. Fortunately, however, the
  1154. CCITT   coding  schemes  can  be   readily  adapted  to  this  different
  1155. environment. The following is one such adaptation.
  1156.  
  1157.  
  1158. Coding Scheme
  1159.  
  1160. A  line  (row) of data is composed  of  a series of variable length code
  1161. words. Each code word represents a run length of either all white or all
  1162. black.  (Actually,  more  than one code word  may  be required to code a
  1163. given  run,  in  a manner described  below.)  White  runs and black runs
  1164. alternate.
  1165.  
  1166. In  order  to  ensure that  the  receiver (decompressor) maintains color
  1167. synchronization,  all data lines will begin with a white run length code
  1168. word  set. If the actual scan line begins  with a black run, a white run
  1169. length  of  zero will be sent (written).  Black or white run lengths are
  1170. defined  by the code words in Tables 1  and 2. The code words are of two
  1171. types: Terminating code words and Make-up code words. Each run length is
  1172. represented  by zero or more Make-up  code words followed by exactly one
  1173. Terminating code word.
  1174.  
  1175. Run lengths in the range of 0 to 63 pels (pixels) are encoded with their
  1176. appropriate  Terminating code word. Note that  there is a different list
  1177. of code words for black and white run lengths.
  1178.  
  1179. Run  lengths in the range of 64 to 2623 (2560+63) pels are encoded first
  1180. by the Make-up code word representing the run length that is nearest to,
  1181. not longer than, that required. This is then followed by the Terminating
  1182. code  word  representing the difference  between the required run length
  1183. and the run length represented by the Make-up code.
  1184.  
  1185. Run  lengths  in the range of lengths  longer than or equal to 2624 pels
  1186. are  coded  first by the Make-up code  of 2560. If the remaining part of
  1187. the  run (after the first Make-up code of 2560) is 2560 pels or greater,
  1188. additional  Make-up code(s) of 2560 are  issued until the remaining part
  1189. of  the run becomes less than 2560  pels. Then the remaining part of the
  1190. run  is encoded by Terminating code  or by Make-up code plus Terminating
  1191. code, according to the range mentioned above.
  1192.  
  1193. It  is  considered an unrecoverable error if  the sum of the run lengths
  1194. for a line do not equal the value of the ImageWidth field.
  1195.  
  1196. New rows always begin on the next available byte boundary.
  1197.  
  1198. No  EOL  code  words  are used. No  fill  bits  are used, except for the
  1199. ignored bits at the end of the last byte of a row. RTC is not used.
  1200.  
  1201.  
  1202.  
  1203.   Appendix C: Data Compression Scheme 32773 PackBits
  1204.  
  1205.  
  1206. Abstract
  1207.  
  1208. This document describes a compression scheme for paint type files. It is
  1209. intended for use in conjunction with the Tag Image File Format.
  1210.  
  1211.  
  1212. 1) Motivation
  1213.  
  1214. The  current  TIFF  specification allows  for  two  compression schemes.
  1215. Compression  type  1  is really no  compression,  other than basic pixel
  1216. packing. Compression type 2, based on CCITT 1D compression, is powerful,
  1217. but  not trivial to implement and is designed for scanned data more than
  1218. data  generated  by  paint  programs.  Simple  byte-oriented  run length
  1219. schemes  tend  to work well with paint  data, since paint data often has
  1220. large areas of white space and areas filled with 8-bit patterns.
  1221.  
  1222.  
  1223. 2) Description
  1224.  
  1225. Since  several  good  schemes already exist, we  may  as well use one of
  1226. them.  We somewhat arbitrarily pick the Macintosh PackBits scheme. It is
  1227. byte  oriented, so there is no problem with word alignment. And it has a
  1228. good  worst  case  behavior (at most 1  extra  byte  for every 128 input
  1229. bytes).  For  Macintosh users, there  are toolbox utilities PackBits and
  1230. UnPackBits  that  will do the work for  you, but it is easy to implement
  1231. your own.
  1232.  
  1233. A pseudo code fragment to unpack it might look like this:
  1234.  
  1235. Loop  until you get the number of unpacked bytes you are expecting: Read
  1236.     the  next  source byte into n. If  n is between 0 and 127 inclusive,
  1237.     copy  the next n+1 bytes literally. Else if n is between -127 and -1
  1238.     inclusive,  copy  the next byte -n+1 times.  Else if n is 128, noop.
  1239.     Endloop
  1240.  
  1241. In  the  inverse  routine, its best to encode  a  2 byte repeat run as a
  1242. replicate  run  except when preceded and  followed  by a literal run, in
  1243. which  case  its  best to merge the  three  into one literal run. Always
  1244. encode 3 byte repeats as replicate runs.
  1245.  
  1246. So thats the algorithm. Other rules:
  1247.  
  1248. Each  row  must  be  packed  separately.  Do  not  compress  across  row
  1249. boundaries.
  1250.  
  1251. The  number of uncompressed bytes per row is defined to be (ImageWidth +
  1252. 7) / 8. If the uncompressed bitmap is required to have an even number of
  1253. bytes per row, decompress into word-aligned buffers.
  1254.  
  1255. If  a  run is larger than 128  bytes, simply encode the remainder of the
  1256. run as one or more additional replicate runs.
  1257.  
  1258. When  PackBits data is uncompressed, the result should be interpreted as
  1259. per  compression  type  1 (no  compression);  i.e.  the SamplesPerPixel,
  1260. BitsPerSample  and  PlanarConfiguration  tags  should  be  consulted  to
  1261. interpret the image.
  1262.  
  1263.  
  1264.  
  1265.   Appendix D: Using the Microsoft Windows Clipboard
  1266.  
  1267. The  Microsoft  Windows  Clipboard  provides  a  mechanism  that  allows
  1268. applications  to  pass  information to  each  other. Pictures created in
  1269. Microsoft  Paint,  for  example, may be  passed  as bitmaps to Microsoft
  1270. Write.
  1271.  
  1272. In  general,  the Clipboard is not recommended  as a way of passing TIFF
  1273. information  between  applications.  The amount  of  data associate with
  1274. image  data  can  be  very large.  Currently,  data  passed  through the
  1275. Microsoft  Windows  Clipboard is limited to  64K  bytes. It is suggested
  1276. that  applications  employ file-based mechanisms  to exchange TIFF data.
  1277. Aldus  PageMaker, for example, implements a  File Place command to allow
  1278. TIFF files to be imported.
  1279.  
  1280. For  images requiring less than 64K bytes  of TIFF data, a new Clipboard
  1281. format has been defined:
  1282.  
  1283.            CF_TIFF Microsoft Tag Image File Format
  1284.  
  1285. (this  symbol will be defined in the windows.h file distributed with the
  1286. Microsoft Windows Software Development Kit.)
  1287.  
  1288. The  data  associated with this format is  a handle to a block of global
  1289. memory  containing the same data as would be stored in a disk TIFF file.
  1290. When  interpreting  this  memory,  TIFF  readers  should  interpret file
  1291. offsets as offsets from the beginning of the memory block.
  1292.  
  1293. Applications  that  are capable of  passing TIFF information through the
  1294. Microsoft  Windows  Clipboard  should  preferably  not  render  the TIFF
  1295. information  until requested to do so.  In addition to passingTIFF data,
  1296. these   applications   should  also   place  bitmaps  (Clipboard  format
  1297. CF_BITMAP) on the Clipboard corresponding to the TIFF data. Applications
  1298. should  judge whether to render these  bitmaps formatted for the display
  1299. or  for  the currently selected output  device.  Placing a bitmap on the
  1300. Clipboard  will allow the Clipboard  viewer application (CLIPBRD.EXE) to
  1301. display  a likeness of the image and will allow non-TIFF applications to
  1302. import,  at  least,  an approximate  bitmap.  These  and other Clipboard
  1303. techniques  are described in the  Microsoft Windows Programming Guide, a
  1304. document in the Microsoft Windows Software Development Kit.
  1305.  
  1306.  
  1307.  
  1308.  
  1309. Appendix E: Numerical List of TIFF Tags
  1310.  
  1311.  
  1312. SubfileType
  1313. Tag     = 255  (FF)
  1314. Type    = SHORT
  1315. N       = 1
  1316.  
  1317. ImageWidth
  1318. Tag     = 256  (100)
  1319. Type    = SHORT
  1320. N       = 1
  1321.  
  1322. ImageLength
  1323. Tag     = 257  (101)
  1324. Type    = SHORT
  1325. N       = 1
  1326.  
  1327. BitsPerSample
  1328. Tag     = 258  (102)
  1329. Type    = SHORT
  1330. N       = SamplesPerPixel
  1331.  
  1332. Compression
  1333. Tag     = 259  (103)
  1334. Type    = SHORT
  1335. N       = SamplesPerPixel for PlanarConfiguration equal to 1 or 2.
  1336.  
  1337. PhotometricInterpretation
  1338. Tag     = 262  (106)
  1339. Type    = SHORT
  1340. N       = 1
  1341.  
  1342. Threshholding
  1343. Tag     = 263  (107)
  1344. Type    = SHORT
  1345. N       = 1
  1346.  
  1347. CellWidth
  1348. Tag     = 264  (108)
  1349. Type    = SHORT
  1350. N       = 1
  1351.  
  1352. CellLength
  1353. Tag     = 265  (109)
  1354. Type    = SHORT
  1355. N       = 1
  1356.  
  1357. FillOrder
  1358. Tag     = 266  (10A)
  1359. Type    = SHORT
  1360. N       = 1
  1361.  
  1362. DocumentName
  1363. Tag     = 269  (10D)
  1364. Type    = ASCII
  1365.  
  1366. ImageDescription
  1367. Tag     = 270 (10E)
  1368. Type    = ASCII
  1369.  
  1370. Make
  1371. Tag     = 271  (10F)
  1372. Type    = ASCII
  1373.  
  1374. Model
  1375. Tag     = 272  (110)
  1376. Type    = ASCII
  1377.  
  1378. StripOffsets
  1379. Tag     = 273  (111)
  1380. Type    = SHORT or LONG
  1381. N       = StripsPerImage for PlanarConfiguration equal to 1.
  1382.         = SamplesPerPixel * StripsPerImage for PlanarConfiguration equal to 2
  1383.  
  1384. Orientation
  1385. Tag     = 274 (112)
  1386. Type    = SHORT
  1387. N               = 1
  1388.  
  1389. SamplesPerPixel
  1390. Tag     = 277  (115)
  1391. Type    = SHORT
  1392. N       = 1
  1393.  
  1394. RowsPerStrip
  1395. Tag     = 278  (116)
  1396. Type    = SHORT or LONG
  1397. N       = 1
  1398.  
  1399. StripByteCounts
  1400. Tag     = 279  (117)
  1401. Type    = LONG
  1402. N       = StripsPerImage for PlanarConfiguration equal to 1.
  1403.         = SamplesPerPixel * StripsPerImage for PlanarConfiguration equal to 2
  1404.  
  1405. MinSampleValue
  1406. Tag     = 280  (118)
  1407. Type    = SHORT
  1408. N       = SamplesPerPixel
  1409.  
  1410. MaxSampleValue
  1411. Tag     = 281  (119)
  1412. Type    = SHORT
  1413. N       = SamplesPerPixel
  1414.  
  1415. XResolution
  1416. Tag     = 282  (11A)
  1417. Type    = RATIONAL
  1418. N       = 1
  1419.  
  1420. YResolution
  1421. Tag     = 283  (11B)
  1422. Type    = RATIONAL
  1423. N       = 1
  1424.  
  1425. PlanarConfiguration
  1426. Tag     = 284  (11C)
  1427. Type    = SHORT
  1428. N       = 1
  1429.  
  1430. PageName
  1431. Tag     = 285  (11D)
  1432. Type    = ASCII
  1433.  
  1434. XPosition
  1435. Tag     = 286  (11E)
  1436. Type    = RATIONAL
  1437.  
  1438. YPosition
  1439. Tag     = 287  (11F)
  1440. Type    = RATIONAL
  1441.  
  1442. FreeOffsets
  1443. Tag     = 288  (120)
  1444. Type    = LONG
  1445.  
  1446. FreeByteCounts
  1447. Tag     = 289  (121)
  1448. Type    = LONG
  1449.  
  1450. GrayResponseUnit
  1451. Tag     = 290 (122)
  1452. Type    = SHORT
  1453. N       = 1
  1454.  
  1455. GrayResponseCurve
  1456. Tag     = 291 (123)
  1457. Type    = SHORT
  1458. N       = 2**BitsPerSample
  1459.  
  1460. Group3Options
  1461. Tag     = 292  (124)
  1462. Type    = LONG
  1463. N       = 1
  1464.  
  1465. Group4Options
  1466. Tag     =  293  (125)
  1467. Type    = LONG
  1468. N       = 1
  1469.  
  1470. ResolutionUnit
  1471. Tag     = 296 (128)
  1472. Type    = SHORT
  1473. N       = 1
  1474.  
  1475. PageNumber
  1476. Tag     = 297  (129)
  1477. Type    = SHORT
  1478. N       = 2
  1479.  
  1480. ColorResponseUnit
  1481. Tag     = 300 (12C)
  1482. Type    = SHORT
  1483. N       = 1
  1484.  
  1485. ColorResponseCurves
  1486. Tag     = 301 (12D)
  1487. Type    = SHORT
  1488. N       = 2**BitsPerSample (for Red sample)+
  1489.                 2**BitsPerSample (for Green sample)+
  1490.                 2**BitsPerSample(for Blue sample)
  1491.  
  1492.  
  1493.  
  1494.